Building an information technology (IT) system requires developing a system architecture that meets specified functional and non-functional requirements. With respect to meeting non-functional requirements, known IT system building techniques are costly, lead to excessively long development cycles, and are marked by performance and stability problems. Conventional risk mitigation strategies for non-functional requirements validation during the development cycle of an IT system are listed below:                Building and testing the IT system before deployment. This approach is the most accurate, but is also excessively expensive because all of the hardware and software must be acquired and the system must be built prior to an assessment of the non-functional requirements.        Testing in a test environment. This strategy is very costly and time-consuming if a production-like test environment is built. If shortcuts are used to build the test environment, such as building less than a full end-to-end system, using stubbed out interfaces, using emulators or simulators, reducing the test scope, etc., then the risk mitigation and the accuracy of the validation is negatively impacted.        Building and testing prototypes. This approach is also expensive and requires at least some of the hardware that the target system is supposed to use. Very often, prototype testing emphasizes functional requirements testing at the expense of non-functional requirements testing.        Capacity and performance simulation modeling. This approach requires having performance data for the system available in order to calibrate the model. Therefore, using this approach requires either having the system available to test or having a test or prototype system available to generate system performance statistics. If actual or test data is unavailable, then the accuracy of the modeling results decreases. In cases in which the modeling approach is used iteratively as more system performance statistics become available, this approach becomes time-consuming. This approach may also require acquiring new hardware before the system performance is validated. Often final results are not available by the time the hardware for the new system must be purchased. Finally, initial estimates may be deficient because of inaccuracies.        Paper and pencil estimation. Although being the fastest and cheapest of the listed conventional methods of estimating predicted performance or required capacity of a system, this approach is the least accurate method and suffers from a number of other drawbacks. This approach is less useful if the system being built is complex because the more complex the system, the more difficult it becomes to keep track of all system components.Thus, there exists a need to overcome at least one of the preceding deficiencies and limitations of the related art.        